Columbia Kermit/kermit.zip/newsgroups/misc.20041116-20060924/[e-mail]_Sat May 13 10:51:55 2006.msg

Internet Message Format | 2020-01-01 | 6KB

Path: newsmaster.cc.columbia.edu!panix!newsfeed.media.kyoto-u.ac.jp!border2.nntp.dca.giganews.com!nntp.giganews.com!cyclone1.gnilink.net!spamkiller2.gnilink.net!gnilink.net!trndny07.POSTED!60760995!not-for-mail
From: John Santos <[e-mail]>
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Another Secure FTP thread -- Protection Levels
Message-ID: <[e-mail]>
References: <[e-mail]> <Q7P6g.35918$[e-mail]> <[e-mail]> <RBl7g.53425$[e-mail]> <[e-mail]> <Ygv7g.36642$[e-mail]> <[e-mail]> <WlL7g.36675$[e-mail]>
Reply-To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
User-Agent: MicroPlanet-Gravity/2.60.2060
Lines: 87
Date: Sat, 13 May 2006 08:00:21 GMT
NNTP-Posting-Host: 71.243.61.168
X-Complaints-To: [e-mail]
X-Trace: trndny07 1147507221 71.243.61.168 (Sat, 13 May 2006 04:00:21 EDT)
NNTP-Posting-Date: Sat, 13 May 2006 04:00:21 EDT
Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:15607

In article <WlL7g.36675$[e-mail]>, jaltman2
@nyc.rr.com says...
> Ed Gage wrote:
> > Your response suggests that there might be other products out there
> > that would have this capability.  If so, what are they?  Alternatively,
> > if we select a router that has a firewall which allows external
> > addresses to map to an internal NAT-protected IP, would that also solve
> > the problem?
>
> Ed:
>
> Didn't this thread start because you had another product that did have
> this functionality and you wanted to know if you could replace it with
> C-Kermit?
>
> Here is your problem.  Your company wants to have secure communications
> between a client that you control and a remote server that you do not
> control.  In order to do this, you must create a mutually authenticated,
> encrypted, and integrity protected channel between your client and the
> remote server.  At no point during the communication session can you
> allow the encryption or integrity protection to drop without becoming
> susceptible to an active attack whereby the attacker waits until the
> authentication has been performed and then steals the tcp session.
>
> At the same time your company doesn't want to allow an communication
> through your firewall that is not authorized.  You are enforcing that
> policy by requiring the firewall to snoop each session and if it is
> FTP either restrict what commands can be sent or logging each command
> that is sent so that there would be evidence of the transfer of a trade
> secret.  This is incompatible with the concept of a secure private
> session between your client and the remote server.
>
> You can't have it both ways.  I don't write insecure applications.
> If you want to hire someone to make your communications insecure you
> can by all means do so.  But if you are going to use software I wrote
> to perform a secure communication then that communication is going to
> be secure.
>
> The whole notion of firewalls acting as the man in the middle is flawed.
> You can't be the man in the middle when using http over ssl/tls to
> communicate with your bank.  Why should you be able to do so when the
> protocol is ftp?
>
> Jeffrey Altman

I think to do this, the OP's company's security people need to set up a
gateway or proxy system (not the firewall) to act as an FTP relay
between his system and the remote system.  There would then be two FTP
connections, his system to the gateway, and gateway (through the
firewall) to the remote system.  He would need to establish his FTP
session to the gateway, telling it via some magic (encoded in the
username or file specification or stored in a config file on the gateway
or ...) that he really wanted to send the file to the remote system (or
that he wanted to pull it back).  The gateway would then set up a
second (encrypted) FTP session to the remote end.  It would receive
packets from the first system, decrypt them, do what ever validation
and logging is needed, re-encrypt them and send them over the 2nd FTP
connection to the remote end.  The same in reverse for the reply
packets.  The encryption between your system and the gateway and the
encryption between the gateway and the remote system need not have any
connection: separate keys, certificates, algorithms, etc.  (He may not
even need any encryption between his system and the gateway; that
depends on how much the security people trust their corporate network.
Most likely it will be required, though.)

The firewall would be coded to allow encrypted traffic from the gateway
server (but not his own system) to the specified remote system, and
rely on the gateway to do the necessary validation and logging.  Both
the gateway and the firewall would be under control of the security
people, not the end users.

You (the OP) could use Kermit to do the FTP client functions on your
system, just as you do (or are trying to do) now.  For that matter, you
could probably implement the gateway system as a giant Kermit macro, too
:-)

I think secure FTP gateways (not sure what they are called) are
available commercially.  At least one company I know of uses one to
send credit card information to the company that actually manufactures
and mails the credit cards to their customers, so it must be fairly
secure.  I don't know if the gateway they are using is home-brew or
COTS.  Maybe the firewall people at the OP's company already have
one - he should ask.


--
John